\chapter{Conclusion}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Sub-Table of Content
%  1- Outcomes
%  2- Future Work
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Our thesis presented the general environment of computer forensics
analysis, and introduced \textbf{Lemona}, our solution for a
monitoring architecture relying on open standards and implementations,
and aiming towards the post-mortem investigation of compromised
systems.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Outcomes
\section{Outcomes}

As we demonstrated with the presentation of \textbf{Lemona}'s
performance and settings, its design makes it possible to
theoretically trace and record the complete activity at the lowest
architectural level of the operating system; thus allowing a global
review of the system's life, while managing to impact the system with
an acceptable overhead, thus remaining satisfyingly usable and
available.

In its current state, \textbf{Lemona} uses a fairly verbose
development approach, forcing programmers to hook themselves into each
\emph{system call} by means of \emph{kernel} patches. However, this
is an efficient approach from a performance standpoint, as shown by
our proof of concept. Feature-wise, \textbf{Lemona} is currently
incomplete and performs raw monitoring of the activity, without
providing user-friendly tools for information processing and
data-mining. This is the obvious next step of our research.

In the long run, \textbf{Lemona} will not only allow a forensics
investigator to determine how and when an attack occured, but also
offer the possibility to review the compromised or exploited resources
and reconstruct the system based on the fine-grained and exhaustive
records it generates, replaying the compromised system's lifecycle
step by step.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Future Work
\section{Future Work}

There are countless possible improvements to \textbf{Lemona}, three of
which are listed below. It could benefit of numerous other variants,
which are currently being studied.

\subsection{Software Integration}

We think \textbf{Lemona} could benefit from other software suites, and
vice-versa. There are many possible bridges between our solutions and
others, which we could use to augment a system's surveillance.


\subsubsection{IDS/IPS Integration}

Conceptualy, \textbf{Lemona} might as well be used as an
\emph{IPS}/\emph{IDS} or interoperate with one. This would of course
require the dynamic analysis of the monitored information. To have
\textbf{Lemona} act as or collaborate with an \emph{IDS}, it would
require its full tracing/reporting/analysis/response process to be
completed in near real-time. Furthermore, to turn \textbf{Lemona} in
or have it operate with an \emph{IPS}, then it would require this same
process to be \emph{atomic} and \emph{real-time}, as we discussed
earlier in our "related work" section. Both solutions would also
require \textbf{Lemona} to be packaged and/or communicate with a
database of exploits' workflows.

\subsubsection{Improvements to the Static Statistical Analyzer}

There are many methods to analyze traces of a monitored system. The
flow of \emph{system calls} can for instance be compared to a database
of well-known exploits, as stated earlier. We could then use pattern
matching techniques to identify attacks spread over longer
timeframes. Several pattern detection mechanisms would be suitable for
this purpose, though they might not be usable in an \emph{atomic} and
\emph{real-time} scheme to turn \textbf{Lemona} into an
\emph{IPS}. They would however be very useful to reduce the noise in
the traces and analyze brand new vulnerabilities.

The analyzer could also rely on new geometrical analysis
methods. These methods typically imply the representation of the
host's activity as a mathematical curve or geometric form, which can
then be compared to a database of preset forms matching the exploits'
database.

Not only might this solution be more efficient to detect attacks, it
could also prove itself more performant in terms of speed.

\subsection{Software Design}

\textbf{Lemona} is a brand new project and its design is still
morphing, both at the low and high levels of the
architecture. \textbf{Lemona} is not designed for performance at the
moment because of the radical changes it goes through on a regular
basis.

We consider revisiting our design to integrate more dynamic and
generic solutions, that would alleviate both the burden of the
developers to integrate new patches and the amount of complexity
required to set up the system.

\subsubsection{Automated Patches' Generation}

Such approaches include \emph{Aspect Oriented Programming} techniques
to automatically generate the \emph{kernel} patches, thus minimizing
the amount of coding required to trace all the system's calls.

This would also make \textbf{Lemona} able to support brand new
system-calls without touching the source code, as long as they conform
to the Linux \emph{kernel} naming conventions.

Though this design might have a performance impact, it is an
interesting approach to consider.


\subsubsection{Libraries}

Our approach to logging, monitoring and reporting is quite modular and
abstract, and it occured to us during the development phase that this
part of \textbf{Lemona} could live as a project of its own.

By defining \emph{APIs} for this purpose, we would also allow other
projects to come up with their own implementation, and come one step
closer towards the drafting of a open monitoring architecture.

